Fixes #1166.

When an error arrives on the connection between resolution of cursor batch
N and the consumer requesting batch N+1, the iterator's next() previously
overrode this.reject with a closure tied to the current batch's promise.
That promise was already settled by cursorFn, so the rejection was a no-op
— only this.active = false took effect. The next next() call then
short-circuited via this.executed && !this.active and returned
{ done: true }, silently completing the iteration with missing rows.

This stores the error alongside the active = false flag and re-throws it
on the next iteration, matching the behavior the caller would have seen had
the rejection landed during a pending batch.

Includes a regression test that simulates the race by triggering
query.reject after the first batch resolves and asserting the next
iterator step throws.